\chapter{Technika programování}
Před počátkem implementace jakékoliv aplikace je vhodné se pozastavit a~promyslet, k čemu bude aplikace sloužit. Zda bude do budoucna rozvíjena, či jednorázově použita, například pro import dat. Na mnoha prezentacích lze pozorovat, jak lze velice snadno a rychle vyvinout aplikaci pomocí té či oné technologie, ale pokud začneme stavět reálnou aplikaci, mohly brzy by vyvstat potíže.

V této kapitole se pokusím rozebrat oba dva přístupy a popsat, v čem je jejich síla.

\section{Rychlý vývoj} \label{sec:fastdev}
Tento přístup lze aplikovat v případě potřeby aplikace pro jednorázovou akci či potřeby rychlého vývoje prototypu.
Pro tento způsob lze bez obtíží použít obě výše zmíněné technologie. 

\subsubsection{Výhody}

\begin{itemize}
	\item rychlost
	\item není nutná hlubší znalost technologie
	\item vhodné pro jednorázové aplikace
\end{itemize}

\subsubsection{Nevýhody}

\begin{itemize}
	\item GUI je silně provázané s výkonným kódem
	\item nemožnost paralelního programování
	\item nepřehlednost
	\item problematické rozvíjení aplikace
	\item nemožnost testování
\end{itemize}

Pomocí designeru lze navrhnout grafické uživatelské rozhraní (GUI) a~implementovat handlery, v \textit{code behind} si vytáhnout potřebná data, která následně lze rychle zobrazit přiřazením do některého z grafických prvků na GUI.

\section{Návrhové vzory}\label{sec:patterns}
Alternativou k rychlému vývoji je pak využití již známých a léty prověřených návrhových vzorů. Jedním z nejznámějších je Model-View-Controller (zkráceně MVC). 

Aplikace je rozdělena do tří oddělených bloků, které jsou na sobě nezávislé. Jednotlivé vrstvy lze modifikovat bez dopadu změn na vrstvy ostatní či vrstvy plně nahradit jinými.

\textit{Model} reprezentuje bussiness logiku aplikace a samotná data, která se mají prezentovat.  \textit{View} tvoří prezentační vrstvu, která zobrazuje uživateli poskytnutá data a \textit{Controller} je prostředník, který má na starosti veškeré toky událostí v aplikaci \cite{zdrojakMVC}.

Vzhledem k tomu, že WPF podporuje tzv. Databinding, lze tento model ,,ušít na míru'' právě této technologii.

\subsection{Model-View-ViewModel} \label{sec:mvvm}
Model-View-ViewModel (zkráceně MVVM) vychází z principů vzoru MVC a byl navrhnut architektem WPF/Silveright Johnem Gossmanem.

\begin{itemize}
		\item Představuje určitého prostředníka, který adaptuje Model pro potřeby View.
	\item Je zodpovědný za stav View, avšak bez nutnosti přímého zjišťování hodnot jednotlivých prvků ve View.
	\item Volá model nebo služby přes jejich interface.
	\item Vystavuje veřejné vlastnosti, které jsou v XAML bindovány. Aby mohlo docházet ke komunikaci mezi View a ViewModelem, je vhodné aby ViewModelem tyto veřejné vlastnosti byly publikovány jako notifikační. To tedy znamená, že:
	\begin{itemize}
		\item jednoduché typy jsou vystaveny pomocí vlastností typu DependencyProperty, případně je na nich implementován interface INotifyPropertyChanged
		\item kolekce prvků jsou vystaveny pomocí ObservableCollection<T> nebo jejích potomků
		\item pro příkazy, které vedou na volání metod modelu/služeb, jsou zpřístupněny commandy přes implementované rozhraní ICommand
	\end{itemize}
\end{itemize}

Výsledek je takový, že \textit{View} se přidělí \textit{ViewModel} jako DataContext a~např. tlačítku se přiřadí, že po stisku má vyvolat příkaz \textbf{BackCommand}. Ať už je příkaz definován či ne, na kompilaci \textit{View} nemá vliv. Tlačítko pouze ví, že má volat příkaz s názvem \textbf{BackCommand} a o~více se nezajímá.

Analogicky např. pro GridView nastavíme, kde má hledat seznam položek, které má zobrazit a kam má uložit referenci právě aktivního řádku a o víc se GridView nezajímá. Jakmile bude z ViewModelu informován o změně seznamu položek, tak se sám obnoví. 

Vzhledem k této nezávislosti lze prostě odmazat prvek GridView a zaměnit jej za ComboBox bez jakékoliv změny na ostatních vrstvách \cite{xaml}.

\subsection{Inversion of Control}
Technika Inversion of Control (IoC) je založena na myšlence vytvářet jednotlivé třídy jako na sobě nezávislé komponenty, které jsou programovány oproti rozhraní a komunikují mezi sebou jen a pouze přes ně. 

Samotné propojení jednotlivých komponent je pak ponecháno na tzv. IoC kontejneru. Tento kontejner je třída, která ví, jakou má vrátit instanci pro dané rozhraní a tento úkol je pouze v její režii. Důsledkem tohoto stylu programování je absence klíčového slova \textit{new} v kódu a veškerá inicializace je ponechána na kontejneru.

Výhodou tohoto programování pak je snadná výměna komponent jedné za druhou, například za třídu sloužící k testování.\cite{iocdi}

\subsubsection{Výhody}

\begin{itemize}
	\item vytváření instancí na základě konfigurace
	\item nastavování životnosti objektů
	\item tvoření tříd jako samostatné komponenty
\end{itemize}

\subsubsection{Nevýhody}

\begin{itemize}
	\item nutnost konfigurace kontajneru
\end{itemize}

\subsection{Dependecies Injection} 

Dependecies Injection (zkraceně DI) je návrhový vzor, který definuje způsob získávání objektů potřebných k jeho činnosti. V praxi se nejčastěji používají dva typy injekce. Prvním je \textit{Constructor Injection}, kde k vytvoření instance objektu je potřeba mít již vytvořené instance parametrů konstruktoru. Druhým typem je \textit{Setter Injection}, kde se vytvoří instance objektu a naplní se všechny její metody označené jako \textit{setter}. \cite{iocdi}

Techniky \textit{IoC} a \textit{DI} se často využívají pospolu a ve výsledku znamenají, že parametry konstruktorů budou rozhraní a kterou instancí budou doplněny, tak se ponechá na konfiguraci IoC kontajneru.

\textbf{Caliburn.Micro} je odlehčený, ale robustní M-V-VM framework, a \textbf{Managed Extensibility Framework} je implementací technik IoC/DI. Největší silou obou těchto nástrojů je jejich snadné propojení a vzájemná kooperace.

\section{Frameworky}

Následující kapitola popisuje frameworky postavené na výčtu návrhových vzorů z kapitoly \ref{sec:patterns}

\subsection{Caliburn.Micro} \label{sec:cm}
Aplikace jakéhokoliv návrhového vzoru na aplikaci bude znamenat jistou režii navíc. Tento investovaný čas na počátku se nám brzy vrátí při budoucích úpravách aplikace, kdy při rychlém vývoji by každý zásah znamenal mnoho programátorských hodin. Tato režie je ale víceméně pořád stejná a např. provazbit View s ViewModelem znamená zkopírovat 5 řádek kódu a pozměnit název cílového ViewModelu.

Pro usnadnění práce byl vytvořen framework Caliburn a jeho mladší a~odlehčený ,,bráška'' Caliburn.Micro. Tento framework vznikl v rukách fenomenálního programátora Roba Eisenberga, který postavil celý projekt na myšlence ,,Convention-over-configuration''.

Pokud budou dodržována jistá pravidla, tak framework bude tyto konfigurace řešit sám. Například výše zmíněné provazbení \textit{View} s \textit{ViewModel}em lze zajistit tak, že namespacu \textit{ViewModel}u odmažeme slova \textbf{Model} a dostaneme cestu k \textit{View}.

\subsubsection{Ukázka úpravy namespace:}
\begin{verbatim}
ViewModel: Zcu.PanelComposer.ViewModels.Pages.HomeViewModel.cs
View: Zcu.PanelComposer.Views.Pages.HomeView.cs

\end{verbatim}
Tato pravidla jsou samozřejmě konfigurovatelná. Dále je zde připraveno mnoho utilit jako je například \textit{Event Aggregator} sloužící k asynchronnímu předávání zpráv např. mezi jednotlivými okny či stránkami. Framework podporuje asynchronní tasky a automaticky provazbuje prvky na \textit{View} s vlastnostmi \textit{ViewModel}u.

Caliburn.Micro si také rozumí s Managed Extensibility Frameworkem (MEF) a ve spojení s technikou Inversion of Control (IoC) a Dependency Injection (DI) se z tohoto frameworku stává robustní nástroj, který programátory víceméně nutí programovat oproti interfacům.

Výhodou tohoto frameworku je také to, že je použitelný pro WPF 4.0/4.5, Silverlight 4.0/5.0, Windows Phone 7.1/8.0 a WinRT (Metro). \cite{caliburn}

\subsection{Managed Extensibility Framework} \label{sec:mef}
Původně skupina nadšenců vytvářela framework, který je postaven na technice IoC/DI, ale nebude fungovat tak, že bude pracovat v rámci jedné aplikace, ale umí prohledávat jednotlivé assembly. Byl vymyšlen mechanismus, který pomocí reflexe prohledá celou assembly a vyhledá pouze třídy, které obsahují specifické atributy. 

Všechny třídy, které reprezentují dané rozhraní, je nejprve nutné implementovat a následně jim přidat atribut \textbf{Export} s typem rozhraní. Analogicky je nutné takto doplnit všechny settery, případně konstruktory, které je třeba  plnit při inicializaci objektu a ty poté rozšířít o atribut \textbf{Import}. 

IoC kontejner pak při spuštění aplikace prohledá všechny dostupné assembly, případně složku, záleží na nastavení, a vytvoří si strom závislostí. Není tedy nutné žádným způsobem kontejner konfigurovat, protože to za nás obstará mechanismus postavený na reflexi.

Tento framework se samotnému Microsoftu natolik zalíbil, že jej zahrnul do .net frameworku od verze 4.0. Pomocí tohoto nástroje lze tak stavět aplikace, které podporují pluginy. \cite{mef}


